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•  UGV  IOP  -  How  does  the  Government  use  it? 
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IOPVO  -  What  is  it? 


•  Defines  hardware  &  software  interface  requirements  for  UGVs 

•  Establishes  the  1st  baseline  for  UGV  interoperability 
requirements 

>  VO  only  addresses  capabilities  that  are  already  fielded  (albeit  not  fielded 
in  a  modular,  interoperable  fashion) 

>  Addresses  point-to-point  interoperability  &  modularity  requirements 
»  UGV  platforms 

»  UGV  payloads  (sensors,  emitters,  actuators) 

»  UGV  radios 
»  UGV  controllers 

•  Primarily  based  upon  the  Joint  Architecture  for  Unmanned 
Systems  (JAUS)  (SAE  AS-4) 
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IOP  Structure 


Overarching  IOP 
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Rules 
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Transports 
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Payloads  IOP 

Control  IOP 

Comms  IOP 
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IOP  Relation  to  Typical  UGV  Architecture 


Payload  #1 


Radio 


Radio 


Operator  Control  Unit 


Operator 


Government  Controlled 
Performance  Spec 


Government  Controlled 
Product  Spec 
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IOP  Relationship  to  UGV  Programs 


FYll 

FY12 

FY13 

FY14 

FY15 

Future  Program  Conformance  to  lOPs  Enforced 
in  Performance/Product  Specs  &  RFPs 
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RSJPO  UGV  lOPs  101 


•  UGV  I0P-  What  is  it? 


•  IOP  VO  -  What  does  it  mandate? 

•  UGV  IOP  -  How  does  the  Government  use  it? 

•  UGV  IOP  -  How  should  industry  use  it? 

•  Additional  Frequently  Asked  Questions 

•  Caveats  &  Managing  Non-Compliant  Interfaces 
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IOPVO  -What  does  it  mandate?  (top  level 
summary) 


•  Mandates  that  if  a  system  is  going  include  "Capability  X",  then 
the  corresponding  IOP  requirements  for  "Capability  X"  will  be 
adhered  to 

•  Mandates  the  use  of  Ethernet  networking  protocol 

•  Mandates  software  message  formats  for  messages  within 
scope 

•  Mandates  2  alternative  physical  connectors 
>  For  platforms,  payloads  and  radios 

•  Mandates  2  alternative  payload  power  values 

•  Mandates  2  alternative  IP  address  management  techniques 

•  Mandates  Common  Control  Link  (CCL)  design  constraints 

•  Recommends  Warfighter/Machine  Interface  (WMI)  design 
practices 
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IOPVO  Content -VO  Capabilities  Plan 


VO  Capabilities  Plan  was  developed  March  2011 
Scopes  &  bounds  what  IOP  VO  will  define 


Focused  on  foundational  capabilities  inhe 
fielded  systems 


UGV  Interoperability  Profile  (IOP) 
Capabilities  Plan 
For 

Version  0 


Robotic  Systems,  Joint  Project  Office  (RS  JPO) 
SFAE-GCS-UGV  MS  266 
6501  East  11  Mile  Road 
Warren,  Ml  48397 


March  11,2011 


ent  in  currently 
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IOPVO  Foundational  Concept- 
interoperability  Attributes” 


•  Every  interoperability  requirement  will  not  be  applicable  to 
every  system 

•  IOP  provides  a  mechanism  to  independently  specify  these 
requirements  in  a  composable  manner,  using  Interoperability 
Attributes. 

•  Interoperability  Attributes  applicable  to  the  specification  and 
design  of  a  system  can  be  identified  and  utilized  to  filter 
applicable  requirements  from  the  UGV  IOP,  supporting  system 
design,  development,  conformance  and  validation  testing, 
initial  operational  test  and  evaluation,  and  fieldine. 

Example:  Interoperability  Attributes  from  Overarching  IOP 


Attribute 

Paragraph 

Title 

Values  1 

UGV  Class 

1.3.2 

UGV  Classes 

Soldier  Transportable, 
Vehicle  Transportable, 

Self  Transportable, 

Applique  Package 

Platform  Databus 

5.2.2 

Databus 

None,  Ethernet 

Transport 

5.6.1.3 

Transport 

UDP,  TCP,  Custom 

Platform 

Management 

5.6.2 

Platform  Management  & 
Platform  Modes 

None,  Basic,  Advanced 

Mobility 

UNCLASSIFIED:  Distri 

5.6.3 

DUtion  Statemi 

Mobility 

ant  A.  Approved  for  public  relea 

Remote  Control, 
Teleoperation,  Basic 
Navigation 

Interoperability  Attribute  Example 


Attribute 

Paragraph 

Title 

Values 

UGV  Class 

1.3.2 

UGV  Classes 

Soldier  Transportable, 
Vehicle  Transportable, 

Self  Transportable, 
Applique  Package 

Platform  Databus 

5.2.2 

Databus 

None,  Ethernet 

Transport 

5.6.1.3 

Transport 

UDP,  TCP,  Custom 

^rratform 

^Managements 

5.6.2 

Platform  Management  & 
Platform  Modes 

Nor^  basic,  Ad^jnced 

5.6.3 

Mobility 

Remote  Control, 
Teleoperation,  Basic 
Navigation 

4 


Requirement  applies  when 
Basic  Platform  Management  is 
selected  for  a  given  system. 


[OVA  Oil]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Basic" 
Platform  Management  Interoperability  Attribute  shall  do  so  by  implementing  the  Platform 
Manager  JAUS  Node  in  accordance  with  the  Basic  Platform  Management  requirements 
specified  in  Section  4.2.1 .1  of  the  UGV IOP  SAE  JAUS  Profiling  Rules. 


4 


Table  4.2-2:  Component  and  Service  Requirements  for  Basic  Platform  Manager 


Basic  Platform  Manager  Component  — — 

Service  — - 

Reference 

urn:jaus:jss:core: Discovery,  vl.O  — 

AS5710  JAUS  Core  Service  Set 

urn:jaus:jss:core:Liveness,  vl.O 

AS5710  JAUS  Core  Service  Set 

urn:jaus:jss:ugv:PowerPlantManager,  vO.1 

AS6091  JAUS  UGV  Service  Set 

urn:jaus:jss:ugv:Odometry,  vO.1 

AS6091  JAUS  UGV  Service  Set 

urn:jaus:iop:platformmanager:PlatformMode,  vl  .0 

Custom  Services,  Messages,  and  Transports 

urn:jaus:iop:platformmanager:HealthMonitor,  vl  .0 

Custom  Services,  Messages,  and  Transports 

urn:jaus:iop:platformmanager:PresetPose,  vl  .0 

Custom  Services,  Messages,  and  Transports 

The  JAUS  Profiling  Rules 
documents  mandates  that 
these  JAUS  services  must  be 
included  in  the  system. 
Additional  guidance  on 
implementation  & 
interpretation  of  the  services  is 
also  provided  in  the  document. 


Additional  detail  on  this  particular  example  provided  later  in  presentation. 
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IOPVO  Content  -  Overarching  IOP 


Provides  the  base  concepts,  architecture,  requirements,  and 
overview  for  the  UGV  IOP 

Specifically  addresses  platform,  payload,  mobility,  on-vehicle 
network,  communication,  and  messaging  requirements. 
Introduces  and  presents  the  conformance  and  validation 
approach  to  be  employed  within  the  IOP. 


Attribute 

Paragraph 

Title 

Values 

UGV  Class 

1.3.2 

UGV  Classes 

Soldier  Transportable, 
Vehicle  Transportable, 

Self  Transportable, 
Applique  Package 

Platform  Databus 

5.2.2 

Databus 

None,  Ethernet 

Transport 

5.6.1.3 

Transport 

UDP,  TCP,  Custom 

Platform 

Management 

5.6.2 

Platform  Management  & 
Platform  Modes 

None,  Basic,  Advanced 

Mobility 

5.6.3 

Mobility 

Remote  ControC\^ 
Teleoperation,  Basic\^ 
Navigation 

4.3  Usage  of  Overarching  IOP 


Example  requirement 
associated  w/  this 
Interoperability  Attribute 
Value 


The  Overarching  IOP  will  be  used  by  the  MATDEV  and  industry  to  serve  as  a 
description  of  the  intent  of  the  full  IOP  package,  to  describe  its  usage,  to  define 
overarching  requirements  for  all  systems,  to  point  to  applicable  sections  in  the  other 
lOPs,  and  to  define  Interoperability  Attributes  that  may  be  selected  by  the  MATDEV  to 
impose  interoperability  requirements  into  acquisition  contracts. 


[OVA  Oil]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  "Basic” 
Platform  Management  Interoperability  Attribute  shall  do  so  by  implementing  the  Platform 
Manager  JAUS  Mode  in  accordance  with  the  Basic  Platform  Management  requirements 
specified  in  Section  4.2. 1.1  of  the  UGV  IOP  SAE  JAUS  Profiling  Rales. 


Innovation 
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IOPVO  Scope  -  Overarching  IOP 
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IOPVO  -  What  does  it  mandate? 
(Overarching  IOP  -  I  of  3) 


General 


[OVA  001]  Robotic  systems  (vehicles)  with  a  designated  '‘Ethernet”  Platform  Databus 
Interoperability  Attribute  shall  provide  an  on-board  Gigabit  Ethernet  databus  IAW  IEEE 
802.3-200S  for  the  integration  of  components  and  payload  subsystems. 


[OVA  002]  The  UGV  platform  shall  supply  power  to  all  base  configuration  payloads. 


[OVA  003]  Payloads  shall  be  implemented  in  accordance  with  the  UGV  IOP  Payloads 
Profile  and  any  required  (specified)  Interoperability  Attributes. 


[OVA  004]  UGV  platforms  shall  implement  the  communications  data  link  interface  in 
accordance  with  the  UGV  SOP  Communications  Profile  and  any  required  (specified) 
Interoperability  Attributes. 


[OVA  005]  Command,  control  and  status  messages  shall  be  implemented  using  the 
3AE  AS-4  JAUS  standards  as  profiled  by  the  UGV  iOP  SAE  JAUS  Profiling  Rules  and 
any  required  (specified)  Interoperability  Attributes. 


[OVA  006]  Custom  command,  control  and  status  messages  shall  be  Implemented  in 
accordance  with  the  RS  JPO,  UGV  IOP  Custom  Services.  Messages  and  Transports. 
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IOPVO  -  What  does  it  mandate? 
(Overarching  IOP  -  2  of  3) 


Platform  Management 

[OVA  010]  Robotic  systems  (controllers  and/or  vehicles)  with  a  Platform  Management 
Interoperability  Attribute  Value  of  “None"  shall  do  so  in  accordance  with  the 
requirements  specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 

[OVA  Oil]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Basic" 
Platform  Management  Interoperability  Attribute  shall  do  so  by  implementing  the  Platform 
Manager  JAUS  Node  in  accordance  with  the  Basic  Platform  Management  requirements 
specified  in  Section  4.2.1 .1  of  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 

[OVA  012]  Robotic  systems  (controllers  and/or  vehicles)  implementing  "Advanced" 

Platform  Management  Interoperability  Attribute  shall  do  so  by  implementing  the  Platform  | 

Manager  JAUS  Node  in  accordance  with  the  Advanced  Platform  Management  ■ 

requirements  specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 

IOPVO  -  What  does  it  mandate? 
(Overarching  IOP  -  3  of  3) 


Mobility 

[OVA  013]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Remote 
Control”  Value  of  the  Mobility  Interoperability  Attribute  shall  do  so  by  implementing  the 
appropriate  JAUS  services  in  accordance  with  the  definition  and  rules  specified  in 
Section  4.3.4  of  the  UG V  IOP  SAE  JAUS  Profiling  Rules. 


[OVA  014]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the 
“Teleoperation’5  Value  of  the  Mobility  Interoperability  Attribute  shall  do  so  by 
implementing  the  appropriate  JAUS  services  in  accordance  with  the  definition  and  rules 
specified  in  Section  4.3.5  of  the  UGV  SOP  SAE  JAUS  Profiling  Rules. 


[OVA  015]  Robotic  systems  (controllers  and/or  vehicles)  implementing  the  “Basic 
Navigation”  Value  of  the  Mobility  Interoperability  Attribute  shall  do  in  accordance  with 
Section  4.3.6  of  the  UGV  IOP  SAE  JAUS  Profiling  Rules. 


Control 


[OVA  016]  Controller  requirements  shall  be  implemented  in  accordance  with  the  UGV 
IOP  Control  Profile. 
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IOPVO  Content  -  Comms  IOP 


Specifies  the  communications  standards,  requirements,  and 


IOPVO  Scope  -  Communications  IOP 
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IOPVO  -  What  does  it  mandate? 
(Comms  IOP) 
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*DHCP  only  required  when  specified 
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Figure  3-2  CCL  Boundary  Diagram 
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IOPVO  -  What  does  it  mandate? 
(Comms  IOP  —  I  of  5) 


Leadership  •  Service  •  Innovation 

UNCLASSIFIED:  Distribution  Statement  A.  Approved  for  puMc  release. 


IOPVO  -  What  does  it  mandate? 
(Comms  IOP  —  2  of  5) 


Radio  Logical  Interfaces  (1  of  2) 
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IOPVO  -  What  does  it  mandate? 
(Comms  IOP  —  3  of  5) 


Radio  Logical  Interfaces  (2  of  2) 
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IOPVO  -  What  does  it  mandate? 
(Comms  IOP  —  4  of  5) 


Radio  Link 
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IOPVO  -  What  does  it  mandate? 
(Comms  IOP  —  5  of  5) 


Encryption 

[COMM  020]  The  radio  shall  be  capable  of  employing  Advanced  Encryption  Standard 
(AES)  with  a  minimum  128-bit  key  length  or  similar  encryption  protocol  that  will  provide 
the  same  or  better  protection. 


[COMM  021]  The  radio  shall  be  able  to  bypass  encryption  using  JAUS  messages  in 
accordance  with  the  Custom  Service  Messages  &  Transports  document. 


RFI  Mitigation 


[COMM  022]  The  radio  communications  system  shall  be  capable  of  changing  the 
frequency  band  of  operation  either  by  swapping  hardware  or  through  software 
commands. 


[COMM  023]  The  communications  link  shall  be  able  to  operate  without  degradation  of 
radio  communications  range  performance  on  second  adjacent  channels  transmitting  in 
the  same  immediate  area  of  operation. 


Data  Rate 


[COMM  024]  The  radio  communications  video  link  shall  support  a  data  rate  of  1 .8  Mbps 
or  better. 


[COMM  025]  The  radio  communications  telemetry  and  audio  link  shall  support  a  data 
rate  of  200  kbps  or  better. 


[COMM  026]  The  radio  communications  link  that  combines  video,  telemetry  and  audio 
products  to  a  single  link  shall  support  a  data  rate  of  2.0  Mbps  or  better. 
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IOPVO  -  What  does  it  mandate? 


Attribute 

Paragraph 

Title 

Values 

Waveform 

3.3 

Air  Interface/  Wraveform 

OFDM, 

COFDM, 

DDL, 

COL, 

None 

OCU  to  Platform 
Communications 

3.5  -  3.6 

Radio  &  T ethered 
Communications 

CCL, 

Optical  Tether, 

Wired  Tether, 

None 

RF  Connector 

4.11.2 

Antenna  Connectors 

SMA-female, 

TNC-female  „ 

N  type-female, 
MMCX-female 

Input  Power 

4.1.2 

Power 

Auto-sense  10-28  VDC 

Network  Interface 
Standard 

4.2.1 

Network  Standard 

Ethernet, 

USB  2.0, 

R3232, 

RS422, 

RS485 

IP  Addressing 

4.2.2 

Addressing  Standard 

IPv4, 

IPv6 

On-board  Network 

4.2.3 

Data  Packet  Handling 

Flat  Network  with  static  IP 
assignment. 

Flat  Network  with  DHCP, 
Routed  Network 

None 

Channel  Bandwidth 
Agility 

4.3.2 

Bandwidth  Selection 

Adjustable, 

None 

Wireless  Encryption 

4.4.1 

Encryption 

AES  128, 

None 

Encryption  Bypass 

4.4.2 

Encryption  Bypass 

Bypass, 

None 

Frequency  Band 
Selectable 

4.5.1 

Frequency  Band  Selection 

Support  Multiple 

Frequency  Bands, 

None 

Data  Rate 

4.6.2 

Data  Rate 

>1.8  Mbps  for  video  , 

>200  kbps  for  telemetry, 
>2.0  Mbps  for  video  and 
telemetry 

None 

Off-Board  Network. 
Attributes 

5. 

Network  Interoperability 
Attributes 

OCU/Platform  PTP 
paired, 

OCU/Platform  PTP 
independent, 

OC  U/Repeater/Platform, 
Mesh/ MANET  Network, 
Cloud  Network 
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IOPVO  Content  -  Payloads  IOP 


Receptacle 

Plug 

-  Sockets 

-  Pins 

-  Platform  Side 

-  Payload  Side 

-  Nominal  Key 

-  Nominal  Key 

Pin  # 

Signal 

PIN# 

Signal 

1 

GND 

B 

C+ 

2 

A+ 

S 

E- 

3 

A- 

ID 

Bf 

4 

D+ 

11 

PWR 

5 

D- 

12 

PWR 

6 

GND 

13 

MA 

Figure  4-2  Interoperability  Connector  “A”  Diagram 


Specifies  the  payload  classification,  standards,  requirements, 
and  conformance  approach. 

4.5  Usage  of  Payloads  HOP 


M  ampul  atof 


(Drive 

tarren 


The  Payloads  IOP  will  be  used  by  the  MAT  DEV  and  industry  to  define  payload  related 
requirements  for  both  payloads  themselves  and  UGV  platforms,  to  point  to  applicable 
sections  in  the  other  lOPs.  and  to  define  payload  related  Interoperability  Attributes  that 
may  be  selected  by  the  IV1ATDEV  to  impose  interoperability  requirements  into 
acquisition  contracts. _ 


c 


LH 


Platform 


1 

4 

J 


-Video 

-Casa 

-  ?E*Vtr 


Figure  1-1  Payload  IOP  Relationships 


IOP 

Paraqraph 

IHe 

Vdues 

Physical  Mounting 

4.3 

Physical  Mounting 

Requ  rements 

P  catinny  Rail  Option 

Optical  Bench  Opt  on 

Power 

4.4 

Electrical  Power 

Requ  rements 

Power  Attrbute  A 

Power  Attrbute  0 

1  nberoperability 

4.5 

Data  Conn  eclian 

Connector  A 

Connector 

Requ  rements 

Connector  E 

General  zed  Sensor 

6 

General  zed  Sensor 

Requ  rements 

Digital  Motion  Imagery 

Analog  Motion  Imageryfc 

Slill  Imagery  \ 

CBRN  Sensor  \ 

Microphone  > 

Range  Finder 

Thermal  Sensor 

PTZ  Camera 

General  zed  Emitter 

9 

General  zed  Emitter 

Requ  rements 

Light 

Speaker 

General  zed  Actuator 

12 

General  zed  Actuator 

Requ  rements 

Basic  Man  pulator 

Basic  Pan  Till  Manipulator 
Telescoping  Mast 

Common  FayEoad 
Requ  iiremenferStandards 


Common  Sensor,  Emitter,  and 
Actuator  Requirements.1  St andandls 


Generalized  Sensor,  Emitter, 
and  Actuator  Requi  rements  \ 1 
Standards  fas  required! 

Specialized  Sensor,  Emitter, 
and  Actuator  Requi  rements  f 
Standards  fas  required,!  may  be 
added  for  very  specific: 
pay I oads 


Example  requirement  associated  w/ 
this  Interoperability  Attribute  Value 


[PAY  009]  Payloads  implementing  the  digital  drive  and  motion  imagery  capability  shall 
do  so  by  Implementing  the  digital  video  component  in  accordance  with  the  definition  and 
rules  specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules,  Section  4.4.1,  and  will 
support  H.264  or  MPEG2  video  standards  at  a  minimum. 
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IOPVO  -  What  does  it  mandate? 
(Payloads  IOP  -  I  of  6) 


IOPVO  -  What  does  it  mandate? 
(Payloads  IOP  -  2of  6) 

Electrical  Power  &  Data 


[PAY  006]  If  a  Power  Interface  Interoperability  Attribute  is  selected,  the  power  provided 
by  the  platform  will  meet  the  requirements  listed  for  the  power  attribute  selected,  and 
the  payload  will  accept  the  power  listed  in  the  power  attribute  that  was  selected. 


Power 

Interface 

Voltage 

Max  Power 
(Watts) 

Max  Current 
(Amps) 

A 

12  VDC 

60  Watts 

5  Amp 

B 

24  VDC 

120  Watts 

5  Amp 

Table  4-1  Power  Attributes 

[PAY  007]  The  data  format  will  be  compliant  with  IEEE  802. Sab  (Gigabit  Ethernet),  as 
defined  by  UGV  IOP  Overarcfiing  Profile 
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ROBOTIC  SYSTEMS  JPO 


IOPVO  -  What  does  it  mandate? 
(Payloads  IOP  -  3of  6) 


Physical  Connectors 


[PAY  008]  If  a  Connector  Interoperability  Attribute  is  selected,  the  connector  will  meet 
the  MIL-DTL-38999L  Series  II  connector  selected,  with  the  keyway  and  pinout  identified 
for  the  connector  listed. 
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Figure  4-2  Interoperability  Connector  “A”  Diagram 
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Figure  4-3  Interoperability  Connector  “B”  Diagram 
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A- 
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16 
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IOPVO  -  What  does  it  mandate? 
(Payloads  IOP  -  4  of  6) 

Video  &  Imagery  Payloads 


[PAY  009]  Payloads  implementing  the  digital  drive  and  motion  imagery  capability  shall 
do  so  by  implementing  the  digital  video  component  in  accordance  with  the  definition  and 
rules  specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules,  Section  4.4.1 ,  and  will 
support  H.264  or  MPEG2  video  standards  at  a  minimum. 


[PAY  010]  Payloads  implementing  the  analog  drive  and  motion  imagery  capability  shall 
do  so  by  implementing  the  analog  video  component  in  accordance  with  the  definition 
and  rules  specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules,  Section  4.4.4,  and  will 
support  the  NTSC  video  standards  at  a  minimum. 


[PAY  011]  Payloads  implementing  the  still  imagery  capability  shall  do  so  by 
implementing  the  still  image  component  in  accordance  with  the  definition  and  rules 

specified  in  the  UGV  JUP  SAE  JAUS  Profiling  Rules,  Section  4.4.2,  and  will  support 

JPEG  or  JPEG2000  image  standards  at  a  minimum. _ 


[PAY  015]  Payloads  implementing  the  thermal  sensor  capability  shall  do  so  by 
implementing  the  appropriate  imagery  component  in  accordance  with  the  definition  and 
rules  specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules,  The  formats  will  be  the  same 
as  those  presented  in  6.1 .1  (for  thermal  motion  imagery)  and  6.1 .2  {for  thermal  still 
imagery)  in  this  document. 


[PAY  016]  Payloads  implementing  the  PTZ  camera  sensor  capability  shall  do  so  by 
using  the  pan  tilt  video  sensor  attribute  in  accordance  with  the  definition  and  rules 
specified  in  the  UGV  IOP  SAE  JAUS  Profiting  Rules. 
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IOPVO  —What  does  it  mandate? 
(Payloads  IOP  -  5  of  6) 


Microphone 


[PAY  013]  Payloads  implementing  the  microphone  capability  shall  do  so  by 
implementing  the  microphone  component  in  accordance  with  the  definition  and  rules 
specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules,  Section  4.4.6. 


Range  Finder 

[PAY  014]  Payloads  implementing  the  range  finder  sensor  capability  shall  do  so  by 
implementing  the  range  finder  component  in  accordance  with  the  definition  and  rules 
specified  in  the  UGV  IOP  SAE  JAUS  Profiling  Rules,  Section  4.4.3. 


CBRN  Payloads 

[PAY  012]  Payloads  implementing  the  CBRN  sensor  capability  shall  do  so  by 
implementing  the  Common  CBRN  Sensor  Interface. 


CCSI  -  http://www.jpeocbd.osd. mil/packs/Default.aspx?pg=860 
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IOPVO  -  What  does  it  mandate? 
(Payloads  IOP  -  6  of  6) 
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IOPVO  Content  -  Control  IOP 


Specifies  Operator  Control  Unit  (OCU)  logical  architecture, 
standards,  Human-Machine  Interface  (HMI)  requirements,  and 
conformance  approach. 


Example:  Defines  Hardware  & 
Software  Access  Levels  for  OCUs 


3.10.41  Panmit 


\ 


ID 


FynotkjruTask 


control  pan/tilt  azimuth 


control  panrtilit  elevation 


view  pam/tilt  functional  status 
[WCA  imclcatons) 


Category 


Payload- 

Pan.Hllt 


Payload- 

Pan.CTilt 


Payload- 

Pan.mit 


Control 
(C|  or 
Status 

x®i 


Access 

Level 


HW, 

SW1 


HW, 

SW1 


SW2 


4,6  Usage  of  Control  IOP 

The  Control  IOP  will  be  used  by  the  MATDEV  and  industry  to  define  desired  common 
qualities  of  controllers.  It  is  acknowledged  that  there  are  a  variety  of  types  of  controllers 
that  make  sense  for  different  missions,  and  the  technology  related  to  controllers  is 
evolving  rapidly,  particularly  based  on  advancements  being  made  in  the  mobile/smart¬ 
phone  and  gaming  markets.  The  current  Control  IOP  VO  contains  desired  guidelines  for 
user  interfaces  for  conventional  controllers,  but  does  not  mandate  explicit  requirements. 
Controllers  must  be  capable  of  communicating  JAUS-based  messages  as  defined  in 
this  IOP  package,  and  must  interface  with  the  CCL  as  defined  in  the  Communications 
IOP.  The  primary  intent  of  the  Control  IOP  is  to  promote  an  interoperable  Human 
Machine  Interface  (HMI),  which  means  that  the  relationship  between  the  controller  and 
the  human  operator  must  be  modular  based  on  minimized  training  for  operation  among 
different  systems.  If  controllers  can  support  the  JAUS-based  messages  described  in  this 
IOP  package,  then  interop  era  ble  messages  will  become  the  interface  between  the 
controller  and  the  UGV  platform. 

For  example,  if  a  controller  operator  presses  a  keypad  arrow  to  turn  right,  then  an 
interpretable  message  command  will  be  received  and  understood  by  the  UGV  platform. 

If  another  controller  utilizes  a  joystick  to  turn  right,  then  the  UGV  platform  should  receive 
an  identical  message  as  that  sent  from  the  first  controller.  Similarly,  user  input  to  turn 
right  on  a  smartphone  type  accelerometer  device,  a  speech-based  device,  a  motion- 
recognition  device,  or  other  innovative  controller  technology  should  all  result  in  an 
identical,  interpretable  JAUS-based  message  being  received  by  the  UGV  platform. 


Graphic 


Reference 
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IOPVO  Scope  -  Control  IOP 
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IOPVO  -  What  does  it  mandate? 
(Control  IOP) 
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IOP  VO  Content  -  SAE  JAUS  Profiling  Rules 


Specifies  the  manner  in  which  the  SAE  AS-4  JAUS  standards 
have  been  profiled 

Includes  clarification  &  additional  content  to  define 
interoperability  between  controllers  and  UGVs  as  well  as  intra- 
UGV  (platform/subsystem)  interoperability.. 
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Figure  3.3-2:  JAUS  Hierarchy  for  Profiled  Requirements 
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IOP  VO  Content  -  SAE  JAUS  Profiling  Rules 
(cont.) 


Message(s) 

Concept 

Interpretations 

ID  4508: 

Re  portPowerP  la  ntStatu  s 

Reporting 

Types 

Only  the  record  or  records  that  apply  to  the  power 
plant  capabilities  of  the  vehicle  shall  be  used  when 
sending  a  Re  portPowerP  la  ntStatu  s  message.  For 
example,  if  a  vehicle  with  a  diesel  engine  and  battery 
is  reporting  information,  it  shall  provide  the 
battery  Status  and  diesel  EngineStatus  record  sp  and 
not  the  gasolineEngineStatus  record. 

ID  4506: 

Re  p  o  rtP  owe  rPlantState 

Reporting 

Types 

For  reporting  engine  RPMP  the  record  corresponding 
to  the  type  of  engine  (either  gasEngineState  for  a 
gasoline  engine  or  diesel  Eng  ineState  for  a  diesel 
engine)  shall  be  used. 

Mobility  Interoperability 


Attribute 


Attributes  [Mobility::’::! 


Core  Mobility 


Drive  Timeout 


Safety  Requirements 


Remote  Control  (RCj 


Teleoperation  (Teleop) 


Basic  Navigation  (BN) 


Leader  Follower  (LFj 


Mobility  Limits 


Velocity  State  Driver 


Modifiers 


Mandatory 


Mandatory 


Mandatory 


Selectable 


Selectable 


Selectable 


Selectable 


Selectable 


Selectable 


Values 


Default 


Default 


Default 


Default 


Default 


Local 


Global 


Default 


Default 


Default 


Parameters 


Drive  Timeout  (default  =  1 
second) 


Drive  Frequency  (default  = 
none) 


Drive  Recovery  Time 
(default  =  1  second) 
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Table  4.1-1:  Core  Attributes 


Attribute 

Name 

Attribute 

Values 

Description 

Core  Sen/ ices 
[Mandatory! 

Default 

Specifies  which  JAUS  core  services  are  required  and  any 
clarifications  on  their  use. 

Access  Control 
[Mandatory] 

Default 

Defines  rules  for  using  JAUS  Access  Control  service  authority 
codes  and  Access  Control  Timeout. 

ID  Assignment 
[Mandatory, 
Mutually 
Exclusive] 

Static 

Uses  static  assignment  of  JAUS  addresses  for  Nodes  and 
Components. 

Centralized 

Uses  a  centralized,  DHCP  like  method  for  assignment  of  JAUS 
addresses  for  Nodes  and  Components. 

IP  Based 

Defines  a  method  for  assigning  JAUS  addresses  based  on  unique 

IP  addresses. 

Transport 

[Mandatory] 

JUDP 

Specifies  that  the  JAUS  over  UDP  transport  is  used  as  specified  in 
AS5669A  JAUS/SDP  Transport  Specification. 

JTCP 

Specifies  that  the  JAUS  over  TCP  transport  is  used  as  specified  in 
AS5669A  JAUS/SDP  Transport  Specification. 

Custom 

Specifies  that  a  custom  transport  is  used. 
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IOPVO  -  What  does  it  mandate? 

(JAUS  Profiling  Rules  -  Representative  Example  - 
Basic  Platform  Management  Required  Services) 


Discovery  Service 

^  Discovery 

The  discovery  service  shall  be  provided  as  specified  as  in  AS5710  JAUS  Core  Service  Set,  with 
the  following  additional  messaging  requirements: 


Table  4.2-3:  Message  Interpretations  for  Discovery  Service 


Message(s) 

Concept 

Interpretations 

ID  2B00:  Queryldentification 

ID  4B00:  ReDortldenfitication 

Finding  and 
Losina 

The  Queryldentification  message  shall  be  sent  by 
each  comoonent  on  a  subsystem  at  a  rate  soecified 

ID  0B00:  RegisterServices 

Subsystem 

Discovery 

Service 

in  the  Periodicity  section.  If  a  corresponding 
Reportldentification  message  is  not  received  within  5 
seconds,  two  more  retries  will  be  attempted.  If 
Reportldentification  is  still  not  received,  the  Discovery 
service  shall  be  considered  lost.  When  a  Discovery 
service  is  found  after  being  considered  lost,  the 
RegisterServices  message  shall  be  sent  to  the 
Discovery  service  containing  information  on  all 
services  the  component  provides,  including  the  core 
services. 

*This  represents  additional  detail  to  example  shown  on  Slide  #12 
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IOPVO  -  What  does  it  mandate? 

(JAUS  Profiling  Rules  -  Representative  Example  - 
Basic  Platform  Management  Required  Services) 


Liveness  Service 

4.2.1. 1.2. 2  Liveness 

The  liveness  service  provided  by  the  Platform  Manager  JAUS  component  shall  be  used  by  an 
OCU  or  other  client  to  maintain  liveness  to  the  Platform  Manager. 


Power  Plant  Manager  Service 


4.2. 1.1.2. 3  Power  Plant  Manager 

The  following  message  interpretations  apply  for  the  Power  Plant  Manager  service: 


Table  4.2-4:  Message  Interpretations  for  Power  Plant  Manager  Service 


Message(s) 

Concept 

Interpretations 

ID  4508: 

ReportPowerPlantStatus 

Reporting 

Types 

Only  the  record  or  records  that  apply  to  the  power 
plant  capabilities  of  the  vehicle  shall  be  used  when 
sending  a  ReportPowerPlantStatus  message.  For 
example,  if  a  vehicle  with  a  diesel  engine  and  battery 
is  reporting  information,  it  shall  provide  the 
batteryStatus  and  dieselEngineStatus  records,  and 
not  the  gasolineEngineStatus  record. 

ID  4506: 

ReportPowerPlantState 

Reporting 

Types 

For  reporting  engine  RPM,  the  record  corresponding 
to  the  type  of  engine  (either  gasEngineState  for  a 
gasoline  engine  or  dieselEngineState  for  a  diesel 
engine)  shall  be  used. 

*This  represents  additional  detail  to  example  shown  on  Slide  #12 
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IOPVO  -  What  does  it  mandate? 

(JAUS  Profiling  Rules  -  Representative  Example  - 
Basic  Platform  Management  Required  Services) 


_ Odometry  Service 

4.2.1. 1.2.4  Odometry 

The  following  message  interpretations  apply  for  the  Odometry  service: 


Table  4.2-5:  Message  Interpretations  for  Odometry  Service 


Message(s) 

Concept 

Interpretations 

ID  0515:  QueryOdometry 

Usage 

A  value  of  PLATFORM  for  the  OdometryType  shall 
be  used  to  request  the  distance  traveled  by  the 
platform  since  it  began  service.  A  value  of  TRIP_A 
shall  be  used  to  query  the  distance  traveled  on  the 
current  trip.  The  current  trip  starts  whenever  an 
external  entity,  such  as  an  OCU,  issues  a 
ResetOdometry  message  with  a  value  of  TRIP A. 

4516:  ResetOdometry 

Usage 

This  message  shall  be  used  with  a  value  of  TRIP_A 
to  start  a  new  trip. 

Health  Monitor  Service 

For  IOP  Version  0,  only  the  QueryComponentHealth  and  ReportComponentHealth  messages  of 
the  Health  Monitor  service  are  required.  For  IOP  Version  0,  only  the  Failure,  Comms  lost,  and 
Emergency  health  states  are  required. 

The  following  message  interpretations  apply  for  the  HealthMonitor  service: 


Table  4.2-6:  Message  Interpretations  for  Health  Monitor  Service 


Message(s) 

Concept 

Interpretations 

IDFF12: 

ReportComponentHealth 

Emergency  and 
Failure  Health 
States 

The  HealthState  field  of  the  ComponentHealthRec 
shall  be  set  to  Failure  or  Emergency  based  on  the 
Management  service  state  of  a  component.  If  a 
component  does  not  provide  a  Management  service, 
these  health  states  are  not  possible. 

Comms  Lost 
State 

If  liveness  to  a  component  is  lost 
(urn:jaus:jss:core:Liveness  service),  the  Health 

Monitor  service  shall  report  health  state  as  3:  Comms 
Lost. 

*This  represents  additional  detail  to  example  shown  on  Slide  #12 
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IOPVO  -  What  does  it  mandate? 

(JAUS  Profiling  Rules  -  Representative  Example  - 
Basic  Platform  Management  Required  Services) 


Platform  Mode  Service 

4.2.1. 1.2.6  Platform  Mode 

There  are  no  notes  or  interpretations  for  Platform  Mode. 

Preset  Pose  Service 


4.2.1. 1.2.7  Preset  Pose 

The  Preset  Pose  service  is  used  to  set  and  query/report  preset  poses  for  a  platform,  where  a 
pose  refers  to  a  particular  orientation  and  position  of  various  arms,  flippers,  and  manipulators. 

The  following  message  interpretations  apply  for  the  Preset  Pose  service: 

Table  4.2-7:  Message  Interpretations  for  Preset  Pose  Service 

Message(s) 

Concept 

Interpretations 

ID  FFFD:  SetPresetPose 

Stow  Pose 

The  Stow  pose  is  defined  as  a  pose  where  all 
actuated  devices  are  in  a  position  that  best  compacts 
the  platform  for  stowing  within  its  container  or  other 
enclosed  area. 

Drive  Pose 

The  Drive  pose  is  defined  as  a  pose  best  suited  to 
normal  driving. 

Deploy  Pose 

The  Deploy  pose  is  defined  as  a  pose  best  suited  to 
deployment  of  a  platform. 

*This  represents  additional  detail  to  example  shown  on  Slide  #12 

Leadership  •  Service  •  Innovation 

UNCLASSIFIEDTDistnUution  Statement  A.  Approved  for  public  release. 


IOPVO  -  What  does  it  mandate? 

(JAUS  Profiling  Rules  -  Representative  Example 
Basic  Platform  Management  Required  Services) 

Periodicity  Guidance  for  Services 


4.2.1. 1 .3  Periodicity 


4.2. 1.1. 3.1  Liveness 

•  ID  2202:  QueryHeartbeatPulse/  ID  4202:  ReportHeartbeatPulse  -  The  Platform  Manager 
JAUS  component’s  Liveness  service  can  be  used  to  maintain  connectivity  to  a  platform. 
A  rate  of  at  least  once  per  5  seconds  is  recommended. 

4.2.1. 1.3.2  Health  Monitor 

•  ID  2202:  QueryHeartbeatPulse/  ID  4202:  ReportHeartbeatPulse  -  The  Health  Monitor 
shall  check  for  connectivity  to  each  JAUS  component  on  the  subsystem  at  a  rate  of  at 
least  once  per  60  seconds  for  every  component  on  the  subsystem,  and  at  least  once  per 
second  for  the  Core  Mobility  JAUS  component. 

4.2 . 1 .1.3.3  Discovery 

•  ID  2B00:  Queryldentification  -  A  Queryldentification  message  shall  be  broadcast  by 
every  JAUS  component  on  the  subsystem  at  a  rate  of  at  least  once  per  5  minutes  for  the 
purpose  of  finding  and  registering  services  with  the  Discovery  service. 


*This  represents  additional  detail  to  example  shown  on  Slide  #12 
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ROBOTIC  SYSTEMS  JPO 


IOPVO  Content  -  Custom  Services,  Messages 
ijpr  &  Transports 


Specifies  additional  SAE  AS-4  JAUS  messages  and  transport 
protocols  required  to  support  the  scope  of  the  UGV  IOP. 
Although  titled  "custom"  these  messages  are  published  with 
the  end  goal  of  transitioning  to  the  SAE  AS-4  JAUS  standard(s) 
for  official  adoption. 


3.3  Communicator  Service 


name=Communicator 
version=0  1 

id=um:jpo:comms:Communicator 


Inherits-from  AccessControl 
name=accessControl 
id=  um:jaus:jss:core:AccessControl 
version=1 .0 


«AccessControl» 


4.8  Usage  of  Custom  Services,  Messages  &  Transports 


The  Custom  Services,  Messages  *  Transports  document  will  he  used  to  define  JAUS- 
based  services  that  .are  mot  currently  defined  in  any  existing  SAE  AS-4  JAUS  approved 


document.  Currently  in  VO  the  Custom  Services f  Messages  «£  Transports  document 
contains  JAUS-based  guidance  for  the  following  Custom  Services:  Leader 
Management,  Leader  Follower  Driver,  Communicator,  Platform  Mode.  Health  Monitor, 
Health  Reporter,  Digital  Stream  Discovery,  and  Preset  Pose.  Currently  there  are  no 
defined  custom  messages  or  custom  transports  in  this  document. 


Record  Name  =  R  eportCom  mun  batorHealth  Rec 

Field  # 

Name 

Type 

Units 

Optional 

Interpretation 

1 

<p  resen-ce_vector> 

unsigned  byte 

2 

<fixed_field> 

BIIT_Re5utt£ 

unsigned  byte 

one 

true 

Enumerartldn  values: 
a-  Passed 

1- Filed 

3 

<fixed_field> 

Latency 

unsigned  short  integer 

second 

true 

scaled  range  - 10.1] 

4 

<fixed_fleld> 

DataRate 

unsigned  short  integer 

one 

true 

Measured  In  Mbps 
scal  ed  range-  JOJDOQ] 

5 

<fixed_field> 

Received  3  ig  nalPower 

unsigned  short  integer 

one 

true 

Measured  In  dErn 
scaled  range  -  [-1 2Q.-201 

6 

<fixed_field> 

ErrorVectorM  agnitude 

unsigned  short  integer 

one 

true 

Percent 

scaled  range  -  [0,1  DO] 

It  is  the  intent  of  the  RS  JPO  for  each  of  the  custom  services,  messages,  and  transports 
defined  in  this  package  to  be  recommended  for  adoption  by  the  SAE  AS^4  JAUS 
Committee,  and  published  in  an  approved  SAE  document.  Once  the  services, 
messages,  or  transports  are  approved  in  a  published  S  AE  document,  this  IOP  package 


will  be  modified  to  reference  the  new  ri  Table  3.3-1 :  communicator  service  vocabulary 


document  as  well). 


Additionally,  proprietary  services,  me* 
into  this  document. 


Message  ID 
[hex) 

Name 

Command 

Input  Set 

2SDD 

QuervCommun  icatorCapa  bi  lity 

false 

2001 

QuervCommun  icatorConflauralion 

false 

2002 

QuervCommun  icatoHealth 

false 

□001 

SetCommu  nicatorConfiauration 

true 

Output  Set 

40OD 

ReportCom  municatorCapa  bil  itv 

false 

4001 

ReportCom  municatorConfip  ura'Jon 

false 

4002 

ReportCom  municalorlHealth 

false 

□002 

SetCommu  nioatorConfiaurationResponse 

false 
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ROBOTIC  SYSTEMS  JPO 


IOPVO  Content  -  Custom  Services,  Messages 
&  Transports 


•  New  Services  defined  in  VO: 

>  Leader  Management 

>  Leader/Follower  Driver 

>  Communicator  (i.e.  radio  messages) 

>  Platform  Mode 

>  Health  Monitor 

>  Health  Reporter 

>  Digital  Stream  Discovery 

>  Preset  Pose 
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RSJPO  UGV  lOPs  101 


•  UGV  I0P-  What  is  it? 


•  IOP  VO  -  What  does  it  mandate? 

•  UGV  IOP  -  How  does  the  Government  use  it? 

•  UGV  IOP  -  How  should  industry  use  it? 

•  Additional  Frequently  Asked  Questions 

•  Caveats  &  Managing  Non-Compliant  Interfaces 
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IOPVO  —  How  does  the  Government  use  it? 


•  RS  JPO  will  instantiate  IOP  for  each  Program  of  Record 

>  Consists  of  "selecting"  which  Interoperability  Attributes  apply,  and  which 
value(s)  are  required  for  each 

>  A  stand-alone  instantiation  document  will  be  included  as  an  attachment 
in  the  program's  RFP 

»  Interfaces  will  be  managed  to  "product  level"  requirements 
»  Modules/subsystems/black-boxes  will  only  be  managed  to  "performance  level" 
requirements 

•  TARDEC  UGV  Interoperability  Lab  will  perform  Verification 

>  Verification  that  lOPs  ensure  interoperability 

>  Verification  that  products  conform  to  lOPs 

•  RS  JPO  will  promote  proliferation  of  IOP  interfaces 

>  Promote  industry  adoption 

>  Promote  adoption  in  all  4  services  (RS  JPO  manages  Army  &  USMC  UGVs) 

>  Promote  adoption/interface  in  UxS  across  services 

>  Promote  interface  into  other  domains  (Army  COE,  manned  systems,  etc.) 

>  Develop  DoDAF  products  (SVs  &  TVs)  around  lOPs  &  promote  adoption  in  DoD  DISR,  etc. 
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IOPVO  —  How  should  industry  use  it? 


Review/understand  IOP  requirements 

Develop  products  IAW  lOPs 

>  Platforms 

>  Payloads 

>  Radios 

>  Controllers 

>  Software  systems 

Voice  technical  concerns  back  to  gov't 
Help  gov't  shape  future  iterations  of  IOP 
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Additional  Frequently  Asked  Questions 


•  How  does  lOPs'  usage  of  JAUS  conflict  with  STANAG  4586? 

•  How  does  lOPs'  usage  of  JAUS  conflict  with  ROS? 

•  What  are  S/W  Operating  System  requirements? 

•  What  does  the  IOP  mandate  for  Information  Assurance? 

•  How  does  IOP  relate  to  AEODRS? 
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How  does  lOP’s  JAUS  preference  relate  to 
STANAG  4586? 


•  UAVs  have  different  technical  requirements  than  UGVs 

•  UAV  control  tends  to  favor  higher  message  reliability  but  can 
tolerate  higher  latency 

>  STANAG  4586  more  appropriate  for  this  circumstance 

>  Aerial  environment  is  less  complex  &  system  autonomy  is  higher 

•  UGV  control  tends  to  favor  lower  latency  but  can  tolerate 

lower  message  reliability  (for  teleoperation) 

>  JAUS  more  appropriate  for  this  circumstance 

>  Ground  environment  more  complex  &  system  autonomy  is  lower 

•  As  UGVs  mature  in  terms  of  autonomy  (or  comms 
enhancements),  standards  such  as  STANAG  4586  may  become 
more  appropriate 
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How  does  lOP’s  JAUS  preference  relate  to 
Robot  Operating  System  (ROS)? 


•JAUS  is: 

>  A  mandated  SAE  standard  for 
unmanned  ground  system 

•  ROS  is: 

>  A  software  framework  (development,  management,  deployment, 
and  run-time  environment)  for  heterogeneous  elements  of  an 
unmanned  system 

>  Open  Source  and  hosts  a  repository  containing  hundreds  of  user 
developed  functionality  specific  packages,  stacks,  elements,  etc. 

•  lOPs  view  ROS  elements  as  functional  modules  with  well 

defined  interfaces 


ging  between  elements  of  an 


JAUS  and  ROS  are  not  incompatible,  however  if  both  are  used  then  care 
must  be  taken  on  dividing  certain  software  functions 
Due  its  widely  distributed  and  rapid  development,  many  functions  of  ROS 
may  currently  be  unreliable  or  subject  to  multiple  interpretations _ 


>  ROS/JAUS  interoperability  is  supportable  through  implementation 
of  a  ROS/JAUS  bridge/interface  device 

•  The  SAE  AS-4  JAUS  Committee  is  evaluating  the  utility  of 

defining  a  JAUS  interface  with  ROS 
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What  are  the  software  Operating  System 
(OS)  requirements? 


•  IOP  does  not  favor  any  particular  OS 

•  The  intent  is  for  any  subsystem  to  use  an  OS  of  their  choosing, 
given  that  they  can  recognize,  understand,  and  send  IOP 
compliant  messages 

>  Anything  internal  to  each  "black  box"  (such  as  algorithms,  etc.)  should  be 
fully  designed  by  its  developer 
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ROBOTIC  SYSTEMS  JPO 


What  does  the  IOP  mandate  for  Information 
Assurance  (IA)? 


•  IOP  does  not  attempt  to  define  how  encryption  requirements 
are  implemented  (i.e.  algorithms,  etc.) 

•  lOP's  focus  is  currently  on  how  to  use  interoperable  messages 
to  accomplish  the  following: 

>  Query/report  available  encryption  types 

>  Turn  off  /  turn  on  encryption  modes 

•  Comms  IOP  does  specify  that  all  IOP/CCL  radios  must  support 
AES-128  encryption,  or  equivalent,  at  a  minimum. 
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How  does  UGV  IOP  relate  to  NavyAEODRS 
Program? 


•  The  Advanced  EOD  Robotic  System  (AEODRS)  Inc.  I  program  was  initiated  prior  to 
the  development  of  IOP  VO. 

•  All  AEODRS  Architecture  Description  Documents  (ADDs),  Module  Performance 
Specs  (MPS'),  and  ICDs  were  reviewed  as  part  of  IOP  VO  development 

•  IOP  VO  represents  a  super-set  to  AEODRS  interface  requirements 

>  AEODRS  interfaces  were  developed  for  a  single  platform 

>  IOP  developed  for  all  future  UGV  platform  types 

•  IOP  VO  is  ~95%  common  w/  AEODRS  interface  requirements;  teams  currently 
working  together  to  resolve: 

>  Discovery  triggering  mechanism  (active  vs.  passive) 

>  JAUS  ID  assignment  schema 

>  Autonomy  &  behaviors  -  AEODRS  includes  some  that  IOP  does  not 

>  Access  control  -  IOP  includes  requirements  that  AEODRS  does  not 

•  NAVEODTECHDIV  is  involved  in  IOP  development 

•  RS  JPO  attends  all  AEODRS  technical  reviews 

•  Intent  is  for  AEODRS  Inc  II  &  Inc  III  to  utilize  lOPs 


Leadership  *  Service  •  Innovation 

UNCLASSIFIED:  Distribution  Statement  A.  Approved  for  puMc  release. 


RSJPO  UGV  lOPs  101 


•  UGV  I0P-  What  is  it? 


•  IOP  VO  -  What  does  it  mandate? 

•  UGV  IOP  -  How  does  the  Government  use  it? 

•  UGV  IOP  -  How  should  industry  use  it? 

•  Additional  Frequently  Asked  Questions 

•  Caveats  &  Managing  Non-Compliant  Interfaces 
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RS  JPO  Interoperability  Effort. . . 


•  Is  in  support  of  modularity 

•  Is  in  support  of  commonality 

•  Is  open  source  and  widely  available 

•  Is  continually  evolving 

•  Is  NOT  a  limit  on  innovation 

•  Is  NOT  a  set  of  proprietary  standards 

•  Is  NOT  an  end  in  itself,  but  a  means  to  an  end 

•  Is  NOT  added  on  at  the  end  of  a  program 

•  Is  NOT  a  replacement  for  systems  engineering 
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Interoperability  vs.  Systems  Engineering 


•  Good  Interoperability  profiles  ensure  that  the  interfaces 
work. 

•  Good  Systems  Engineering  ensures  that  the  system  works. 


If  the  interfaces  connect,  draw  power,  and  pass 
correct  data  messages,  they  are  interoperable. 

This  does  not  necessarily  mean  that  the  system 
will  work  well,  or  be  practical. 

The  resultant  system  may  even  be  detrimental, 
without  good  systems  engineering! 
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Interoperability  Caveats 


In  other  words,  a  system  that  is  interoperable  may  not 
necessarily  be  a  very  good  system. 

In  a  perfect  world,  interoperability  does  not  care  what  is  on  the 
other  side  of  the  interface. 


IOP  only  is  concerned  with  this! 
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Interoperability  Common  Misconceptions 


•  Certain  capabilities  have  nothing  to  do  with  interoperability, 
although  they  are  supported  by  some  interoperability  attributes 


>  For  example,  stair  climbing 

»  Stair  climbing  is  not  something  that  lOPs  need  to  specify 

»  However,  the  mobility  &  actuation  related  interoperable  messages  can  be  used  to 
provide  stair  climbing 

»  Also,  interoperability  can  enable  management  of  different  poses  or  modes,  one 
of  which  may  be  stair  climbing 
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Interoperability  -  Examples 


•  Interoperability  will  allow  a  500  lb  arm  to  be  added  to  a  10  lb 
robot  as  long  as  the  interfaces  are  correct. 

•  Interoperability  will  allow  RF  to  be  used  as  long  as  both  sides 
meet  the  correct  interfaces,  even  if  the  environment  is  a  series 
of  steel  plates.  Practical  solution  may  suggest  a  fiber  optic 
tether. 
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Use  of  the  lOPs 


•  The  RS  JPO  IPT  will  select  which  portions  of  the  IOP  will  be 
used,  for  a  given  program. 

•  In  most  cases,  one  of  the  accepted  interface  standards  will  be 
used. 

•  In  some  cases,  other  interfaces  may  be  used  with  the 
understanding  that  the  system  may  not  be  interoperable  with 
other  systems. 

>  This  decision  will  be  made  by  the  RS  JPO  IPT  after  assessing  the  design 
trade  space  for  the  system. 
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Hypothetical  Example  #1 
5  Pound  Robot 


•  Attributes  selected: 

>  No  standard  physical  interfaces 

>  No  standard  power  standard 

>  Use  the  RF  radio  standards 

>  Use  the  JAUS  messages 

•  What  does  this  allow? 

>  The  system  can  be  small  and  energy  efficient 

>  The  robot  can  be  controlled  by  other  controllers 
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Hypothetical  Example  #2 
Modular  Robot 


•  Attributes  selected: 

>  Use  4  Picatinny  rails,  4  "B"  connectors 

>  Use  the  24  volt  system 

>  Use  the  JAUS  messages 

•  What  does  this  allow? 

>  Any  new  payload  that  can  be  attached  to  a  Picatinny  rail,  that  uses  24 
VDC,  "B"  connectors,  and  communicates  with  the  JAUS  messages  will 
work  with  the  system 
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Hypothetical  Example  #3 
Partial  Interoperable  Robot 


•  Attributes  selected: 

>  Use  the  JAUS  messages  for  2  payload  ports 

>  Use  the  "B"  style  connectors  at  12  VDC 

>  Allow  the  use  of  vendor  specific  connectors,  cameras,  and  arms  for  all 
other  devices 

•  What  does  this  allow? 

>  The  robot  can  use  camera,  arms,  etc...  optimized  for  use  on  this 
platform,  while  also  allowing  for  additional  interoperable  payloads  in  the 
future 
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Interoperability  Capabilities  Implementation 
Thought  Process 

If  common  messages  are  used  by  both  the  sender  and  receiver 
of  information,  then  interoperability  can  be  achieved. 

Each  element  of  a  system  knows  what  messages  to  expect. 
Each  element  of  a  system  knows  what  messages  to  send. 


Incoming  Message 


Outgoing  Message 


Incoming  Message 


Outgoing  Message 


System  element  exhibits 
some  behavior  when  it 
receives  a  given  message 
that  it  recognizes. 


System  element  exhibits 
some  behavior  when  it 
receives  a  given  message 
that  it  recognizes. 
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Interoperability  Capabilities  Implementation 
Thought  Process  (cont.) 

We  need  to  specify  what  the  messages  are. 

Messages  themselves  become  the  interfaces. 

System  /  subsystem  developers  know  which  messages  to 
expect  coming  in. 

System  /  subsystem  developers  know  which  messages  need  to 
be  sent  by  their  elements. 

Processes  &  algorithms  within  the  "black  boxes"  use  the 
messages  &  remain  proprietary  and  invisible  to  others 


Incoming  Message 


Outgoing  Message 


Incoming  Message 


■> 


Outgoing  Message 


■> 


Incoming  Message 


Outgoing  Message 


■> 


Incoming  Message 

Leadership 


Incoming  Message 


Outgoing  Message 


■> 


Operator 
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Outgoing  Message 

> 

Innovation 

J  for  public  release. 


Interoperability  Capabilities  Implementation 
Thought  Process  (cont.) 


•  Additional  things  need  to  be  defined  to  1)  facilitate  proper 

delivery  of  messages  and  2)  enable  modularity: 

>  Physical  interfaces  (enabling  modularity,  as  well  as  adequate  throughput 
of  messages  &  power  for  messages  to  flow) 

>  Information  handling  techniques  &  protocols  (enabling  reliability  of 
message  delivery,  flow  control,  message  routing,  etc.) 

>  Human  understandable  messages  for  interaction  between  the  operator 
and  the  OCU 
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Managing  Non-compliant  Interfaces  in  the  IOP 
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ROBOTIC  SYSTEMS  JPO 


Managing  Non-Compliant  Interfaces  - 
fM,  Assumptions 


•  JAUS  terminology  is  used  except  where  specified 

>  i.e.  system,  sub-system,  component,  service  -  all  are  used  in  the  context  of  JAUS  terminology 

•  "Payload"  -  IOP  terminology 

•  "P/E/L"  -  "physical/electrical/logical" 

•  "Blackbox" 

>  From  Wikipedia:  "In  science  and  engineering,  a  black  box  is  a  device,  system  or  object  which  can  be 
viewed  solely  in  terms  of  its  input,  output  and  transfer  characteristics  without  any  knowledge  of  its 
internal  workings,  that  is,  its  implementation  is  "opaque"  (black).  Almost  anything  might  be  referred  to 
as  a  black  box:  a  transistor,  an  algorithm,  or  the  human  mind." 

>  For  the  purposes  of  the  IOP  "the  black  box...": 

»  May  or  may  not  be  IOP  compliant 
»  Will  have  well  defined  interfaces 

»  May  or  may  not  be  an  aggregation  of  other  "black  boxes" 

»  May  or  may  not  host  own  computational  unit 
»  May  or  may  not  host  own  communication  channel 
»  May  or  may  not  host  own  power  source 
»  ... 

>  AEODRS  calls  this  a  "capability  module" 
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Non-compliant  Definition 


system 


A  black  box  that  was  not  standardized  by  the  IOP,  and  therefore  cannot  (easily)  be  added 
into  and  work  with  an  IOP  profiled  system.  In  other  words,  one  or  more  of  the  interfaces 
are  different,  be  it  physical,  electrical,  or  logical,  or  a  combination  thereof. 

AEODRS  calls  this  "non-compliance"  WRT  their  systems  and  sub-systems  interfaces. 
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Simple  Determination  of  Non-compliance 


its  simplest: 

If  it  can't  be  physically  attached  because  the  IOP  doesn't  define  the  physical 
interface  for  it. 

If  it  can't  be  electrically  attached  because  the  IOP  doesn't  define  the  electrical 
connector  for  it. 

If  it  can't  be  logically  attached 

»  because  it  doesn't  use  JAUS 

»  because  it  doesn't  use  another  IOP  mandated  standard 
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ROBOTIC  SYSTEMS  JPO 


Options  for  Interfacing  with  Non-compliant 
Black  Boxes 


"Wrap  and/or  Adapt" 

•  Refers  to  any  means  of  translation  (P/E/L 
or  a  combination  thereof)  between  one 
interface  and  another 

>  i.e.  "wrappers"  or  "adaptors" 

•  Example: 

>  Physical  adaptor 

>  Electrical  adaptor 

>  Logical  adaptor  (software  bridge) 


"Adoption" 

•  Adoption  refers  to  the  addition  of  a 
standard  interface  to  the  IOP  Profiles 

•  Examples: 

>  Digital  video  standards,  adopted  in  VO 

>  The  CCSI  for  CBRN  payloads,  adopted  in  VO 

>  "Wrap  and/or  Adapt"  may  be  necessary  for 
translation  between  adopted  standards 
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Black  Box  Examples 


Reminder:  A  black  box  may  or  may  not  be  IOP  compliant. 
OCU 

Robotic  platform 

Sensor/emitter/actuator 

C2  system 

Database 

GIG 

Human 

Others... 
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Interfacing  Between  Black  Boxes 


Black  Box 

IOP  Compliant  Interfaces 

Black  Box 

P/E/L 

.£  < 

Black  Box 

IOP  Cor^i 

pliantJnterfaces 

5  ^ 

Black  Box 

Black  Box 


IOP  Compliant 
Interfaces 


Private  Interfaces 


Black  Box 


P/E/L:  "physical/electrical/logical 
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ROBOTIC  SYSTEMS  JPO 


Interfacing  Between  Black  Boxes: 
Adoption  Example 


4 


•  This  means,  there  are  multiple  standards  for  interfaces. 

•  Could  also  mean  that  somewhere  within  the  system  there  is/are 
wrappers  and/or  adaptors  for  translation  between  the  standards 
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All  of  These  Are  “Compliant” 


Case  1: 

>  Normal  IOP  compliant  black  box 

Case  2: 

>  Black  box  with  the  wrapper  built  in 

>  The  "Robot"  does  not  notice  a  difference,  as  all  messages  and  interfaces  are  IOP  compliant 

Case  3: 


[  All  of  these  are  valid  configurations,  ^ 
but  one  may  be  better  than  another 
fora  given  situation.  There  is  no 
substitute  for  "correct"  systems 
design! 


>  An  adapter/wrapper  was  built  and  inserted  between  the  black  boxes 

>  The  "Robot"  does  not  notice  a  difference,  as  all  messages  and  interfaces  are  IOP  compliant 

•  Case  4: 

>  The  "X"  standard  has  been  "adopted"  by  the  IOP  profiles 

>  This  could  imply  software  adaptors  at  specific  places  within  the  system 

>  This  could  also  imply  new  IOP  standard  electrical  connectors,  physical  requirements  (i.e. 
new  mounting  system,  threading,  etc.)  as  well  as  new  communications  channels  -  ALL  of 
these  would  be  profiled  by  the  IOP  upon  introduction  of  the  new  standard 
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IOP  Mapping  for  Program  Instantiation 


•  A  business  process  for  determining  how  to  map  IOP  attributes  to  an  emerging  program  is  a  must 

>  CDD/CPDs  are  concerned  with  overall  "high-level"  capabilities  requirements 

>  The  IOP,  where  necessary,  will  break  those  "high-level"  concepts  into  "enabling"  capabilities 

•  Ideally  this  process  is  transparent 

>  i.e.  we  don't  care  where  in  a  system  you  place  an  IOP  compliant  black  box,  because  we  already  defined  the  IOP  attributes 
associated  with  its  P/E/L  interfaces. 

•  Identification  of  something  that  is  non-compliant  at  an  early  stage  allows  for 

>  Wrap  and  Adapt 

>  Adoption 

>  Considerations: 

a)  Is  it  in  development?  If  so  can  its  interfaces  be  influenced? 

b)  Does  it  have  its  own  standard?  Can  we  adopt  the  standard? 

c)  Can  it  be  adapted  without  effecting  expected  system  results? 

d)  Is  it  organic  to  the  platform?  Example:  speedometer  on  a  jeep  -  the  interface  may  be  very  different  from  an 
already  defined  speedometer  interface  through  the  IOP 

e)  Other?  TBD 

•  The  entire  process  is  most  likely  iterative  in  nature  with  deliverables  and  feedback  by  the  lOP-team  and  the 
program's  design  team  at  different  times 
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